Distributed applications are characterized by components that run on different machines, typically in communication via a network, such as the Internet. For example, a shift towards interactive Web 2.0 applications has led to development of truly distributed systems where code is written in different languages, runs on multiple machines, and interacts in complex ways. Today, many such applications are written in an ad-hoc manner, where the server and client-side functionality are developed at the same time—but separately and often in different programming languages—and subsequently combined. This approach, which involves heterogeneous languages and runtime systems, such as the .NET platform (Microsoft Corporation, Redmond, Wash.) or the Java 2 Platform, Enterprise Edition (J2EE) (Sun Microsystems, Inc., Santa Clara, Calif.) platform on the server and the JavaScript interpreter together with dynamic HTML (DHTML) on the client makes development more difficult and error-prone, additionally, it requires developers to master multiple programming languages and paradigms.
To build distributed applications a developer, or developers, may rely on Asynchronous JavaScript and XML (AJAX). AJAX forms a method of building interactive applications for the Web that can process user requests immediately. AJAX combines several programming techniques including JavaScript, DHTML, Extensible Markup Language (XML), cascading style sheets (CSS), the Document Object Model (DOM), and the object, XMLHttpRequest. AJAX allows content on Web pages to update asynchronously when a user performs an action; as opposed to the traditional mechanism in which users must wait for a whole new page to load. For example, using AJAX, a weather forecasting site could update local conditions on one side of the page as a user types in a zip code. AJAX has been the enabling technology behind many of the “Web 2.0” applications that have become very popular.
A recent trend is to develop web applications in a unified manner and then distribute them afterwards through an automatic or semi-automatic technique. Technologies aimed at unified development include the ASP.NET AJAX framework (Microsoft Corp.), Google Web Toolkit (GWT) (Google, Inc., Mountain View, Calif.), Script#, and Volta (Microsoft Corp.). The ASP.NET AJAX framework allows for creation of Web pages that include a rich user experience with responsive user interface (UI) elements. ASP.NET AJAX provides client-script libraries that incorporate cross-browser ECMAScript (JavaScript) and dynamic HTML (DHTML) technologies, and it integrates them with the ASP.NET 2.0 server-based development platform.
AJAX can enhance various aspects of client-server interaction. For example, in a typical client-server interaction in a Web application, a user may initiate an action that causes the user's browser to request a page from a server. The user interacts with the page via the browser and when some action from the user requires data from the server, a complete page refresh occurs to update part of the page based on the input. Unfortunately, this behavior does not allow the user to continue interacting with the page; instead, the user must frequently pause while working with the Web application. AJAX allows a shift away from complete page refreshes. In an ASP.NET AJAX application, the initial HTML is retrieved and subsequent calls to the server get requested data in XML, JavaScript Object Notation (JSON), or snippets of HTML, and can update the page incrementally. The background asynchronous calls invoke Web services or retrieve page changes without forcing users to pause for complete page refresh. These asynchronous calls manage updated view state information for subsequent server postbacks so that when a complete page refresh is necessary, the accurate state of the page is carried to the server.
Unified development approaches are attractive because all code can be developed on a single platform (e.g., a server), then refactored to generated tier-specific code (e.g., client tier, server tier, etc.) and distributed as appropriate. However, such an approach can complicate or even prevent performance tracking and optimization as the connection between a distributed component and its original code can be obscured by the transformations performed on it. However, the need for such performance information is greater because the performance of applications developed in this way can be significantly slower compared to applications that are entirely hand-coded. For example, the Atlas-generated analog of the Google.com/ig homepage (http://dropthings.com) is over an order of magnitude slower than the original. Similarly, distributed application code that is produced by Script# and Volta software may provide less than optimal performance.
With respect to Volta software, this technology provides a framework for unified development of distributed applications. The framework includes a set of tools for refactoring web applications. These tools allow a developer to develop their application without consideration of the distributed nature of the application and then and then automatically refactor the code, for example, into client-side/server-side components, server-side/database-side components, or into a variety of client-side runtime components (e.g., JavaScript, Flash, etc.).
Although unified development environments offer many benefits, they can obscure an explicit understanding of performance, which occurs because many transformations are performed on the code during the automatic distribution process. These transformations make it difficult to correlate slow-running automatically generated code with the original code written by the developer. Another complicating factor is when the application is spread across multiple machines. Even if performance profiling is accomplished through conventional techniques separately on the server and the client, correlating and connecting two separate profiles is a non-trivial problem.
Traditional performance profiling is good at summarizing function- and line-level performance information. However, it is very difficult to elevate this low-level information to the “architectural level.”. For example, given function-level performance profiles, how does one answer more high-level questions, such as: “How much time is spent on network activity?”, “How much time is spent waiting for the database to retrieve the data?”, or “How much time does the client-side processing of data take?”. In many case it is much more beneficial to understand application performance in the context of these high-level questions and usage scenarios.
As described herein, various exemplary techniques provide for end-to-end visibility of performance metrics for distributed applications. Such techniques can be applied to applications developed in a unified framework or applications having components developed separately.